Data block modification

ABSTRACT

A method of modifying a data block of a data structure comprising a plurality of linked data blocks comprising: receiving a selection of said data block comprising block data; creating modified block data; transmitting a request to a plurality of validator devices over a network, said request comprising a modification record and requesting permission to modify said data block in accordance with the modified block data; determining that consensus is reached by the plurality of validator devices that said data block can be modified in accordance with the modified block data; in response to said determining: modifying said data block in accordance with the modified block data; and adding a modification data block to the data structure, the modification data block comprising: the modification record and a cryptographic hash of a data block that precedes the modification data block after addition of the modification data block to the data structure.

CROSS-REFERENCE TO RELATED APPLICATION

This application is related to and claims priority under from UnitedKingdom Patent Application No. 1916291.6 filed Nov. 8, 2019 entitled“Data Block Modification,” the entire contents of which is incorporatedherein by reference for all purposes.

BACKGROUND

Blockchains, and more generally distributed ledger technologies, areemerging as a fundamental building block of new digital communicationsplatforms. The ability to securely store, trade, and compute data in ashared responsibility system with no single central point of authorityis a very powerful architecture.

One of the most important and powerful features of a blockchain andother distributed ledger technologies is its immutability. That is, ablockchain provides a permanent, indelible, and unalterable history ofdata.

In a standard blockchain or cryptographic ledger the immutability andintegrity of the chain is maintained through a chain of hashes: thecryptographic hash of each block stored in its successor so as to linkthem together and make it impossible to modify, add, or remove anythingfrom a block in the chain.

SUMMARY

There are many legitimate reasons why it may be necessary to alter thecontents of a blockchain. In a traditional blockchain implementationthere are only 3 options: (1) leave the data there and face theconsequences, (2) change the data and break the chain, or (3) go back tothe block you want to change and manipulate the consensus mechanism tocreate and force a fork.

The inventors have identified that all of these options have significantdownsides. In the prior art, depending on the design in use, thefollowing problematic features are present: (i) the data simply cannotbe changed; (ii) the data can be changed, but then the chain fails toverify from that point forwards (meaning none of the data can betrusted), or (iii) the data can be changed, and the chain's integritydata can be rebuilt, but then nobody knows the change was made, andevery transaction after the one being changed has to be re-created,offering the possibility for additional (and also undetectable) changesto history.

In embodiments of the present disclosure there is provided a systemwhich enables transactions to be modified (e.g. changed or redacted)with the following desirable properties: (i) the chain remainsverifiable; (ii) the changed block is easily identifiable; (iii) theparticipants in creating the change are clearly identified; and (iv) theparticipants in creating the change are in the same security context asthe participants in the consensus mechanism.

According to one aspect of the present disclosure there is provided amethod of modifying a data block of a data structure comprising aplurality of linked data blocks, the method implemented on a computingdevice, and comprising: receiving a selection of said data blockcomprising block data; creating modified block data based on the blockdata and user input received at the computing device; transmitting arequest to a plurality of validator computing devices over acommunication network, said request comprising a modification record andrequesting permission to modify said data block in accordance with themodified block data, wherein said modification record comprises (i) atleast one data portion identifier of said block data, each of the atleast one data portion identifier associated with a respective dataportion of said data block modified in creating the modified block data;(ii) modification information; (iii) a cryptographic hash of said datablock when comprising the block data; (iv) a cryptographic hash of saiddata block when comprising the modified block data; and (v) an integritymeasure; determining that consensus is reached by the plurality ofvalidator computing devices that said data block can be modified inaccordance with the modified block data; in response to saiddetermining: modifying said data block in accordance with the modifiedblock data; and adding a modification data block to the data structurecomprising the plurality of linked data blocks, the modification datablock comprising: the modification record and a cryptographic hash of adata block that precedes the modification data block after addition ofthe modification data block to the data structure.

The modification information may comprise the modified block data.Alternatively, the modification information may comprise instructions onhow to generate the modified block data.

The modification record may additionally comprise a block identifierassociated with said data block.

The modification record additionally comprises a reason specifying whythe data block is being modified.

The modifying the data block may comprise one or more of: redacting datain a data portion of said data block; deleting data in a data portion ofsaid data block; replacing data in a data portion of said data blockwith replacement data; and adding new data to a data portion of saiddata block.

The integrity measure may comprise at least one digital signature.Additionally or alternatively, the integrity measure may comprise atleast one Message Authentication Code. Additionally or alternatively,the integrity measure may comprise at least one cryptographic hash.

The modification data block may additionally comprise the modified blockdata.

The data structure comprising the plurality of linked data blocks may bestored in memory of the computing device.

The data structure may be structured in accordance with a distributedledger technology. The distributed ledger technology may be blockchain.

According to another aspect of the present disclosure there is provideda computer-readable storage medium comprising instructions which, whenexecuted by a processor of a computing device cause the computing deviceto perform the method steps described herein.

The instructions may be provided on a carrier such as a disk, CD- orDVD-ROM, programmed memory such as read-only memory (Firmware), or on adata carrier such as an optical or electrical signal carrier. Code(and/or data) to implement embodiments of the present disclosure maycomprise source, object or executable code in a conventional programminglanguage (interpreted or compiled) such as C, or assembly code, code forsetting up or controlling an ASIC (Application Specific IntegratedCircuit) or FPGA (Field Programmable Gate Array), or code for a hardwaredescription language.

According to another aspect of the present disclosure there is provideda computing device for modifying a data block of a data structurecomprising a plurality of linked data blocks, wherein the data structureis stored in memory accessible to the computing device, and thecomputing device comprising a processor configured to: receive aselection of said data block comprising block data; create modifiedblock data based on the block data and user input received at thecomputing device; transmit a request to a plurality of validatorcomputing devices over a communication network, said request comprisinga modification record and requesting permission to modify said datablock in accordance with the modified block data, wherein saidmodification record comprises (i) at least one data portion identifierof said block data, each of the at least one data portion identifierassociated with a respective data portion of said data block modified increating the modified block data; (ii) modification information; (iii) acryptographic hash of said data block when comprising the block data;(iv) a cryptographic hash of said data block when comprising themodified block data; and (v) an integrity measure; determine thatconsensus is reached by the plurality of validator computing devicesthat said data block can be modified in accordance with the modifiedblock data; in response to said determination: modify said data block inaccordance with the modified block data; and add a modification datablock to the data structure comprising the plurality of linked datablocks, the modification data block comprising: the modification recordand a cryptographic hash of a data block that precedes the modificationdata block after addition of the modification data block to the datastructure.

According to another aspect of the present disclosure there is provideda method of verifying a data structure comprising a plurality of linkeddata blocks, the method performed on a computing device, and comprising:

for a first data block at a beginning of the data structure: computing acryptographic hash of the first data block; determining if thecryptographic hash of the first data block matches a cryptographic hashstored in a successor data block of the first data block, and if thecryptographic hash of the first data block does not match thecryptographic hash stored in the successor data block of the first datablock, storing information associated with the first data block as anentry in a list stored in memory accessible by the computing device;

analysing each subsequent data block in the data structure after saidfirst data block by: determining if said subsequent data block is amodification data block, wherein if said subsequent data block is not amodification data block, the method comprising: computing acryptographic hash of the subsequent data block; determining if thecryptographic hash of the subsequent data block matches a cryptographichash stored in a successor data block of the subsequent data block, andif the cryptographic hash of the subsequent data block does not matchthe cryptographic hash stored in the successor data block of thesubsequent data block, storing information associated with thesubsequent data block as an entry in said list;

wherein if said subsequent data block is a modification data block, themethod comprising: verifying an integrity measure of the modificationdata block; if said verifying the integrity measure of the modificationdata block is successful, determining that information in themodification data block matches information of a matching entry in saidlist, and in response, removing said matching entry from said list; inresponse to completion of said analysing, successfully verifying thedata structure based upon detecting that said list comprises no entries.

The method may comprises determining that verifying the data structurehas failed if said verifying the integrity measure of the modificationdata block is unsuccessful.

In response to completion of said analysing, the method may comprisedetermining that verifying the data structure has failed upon detectingthat said list comprises one or more entries.

According to another aspect of the present disclosure there is provideda computing device for verifying a data structure comprising a pluralityof linked data blocks, wherein the data structure is stored in memoryaccessible to the computing device, and the computing device comprisinga processor configured to: for a first data block at a beginning of thedata structure: compute a cryptographic hash of the first data block;determine if the cryptographic hash of the first data block matches acryptographic hash stored in a successor data block of the first datablock, and if the cryptographic hash of the first data block does notmatch the cryptographic hash stored in the successor data block of thefirst data block, storing information associated with the first datablock as an entry in a list stored in memory accessible by the computingdevice; analyse each subsequent data block in the data structure aftersaid first data block by:

determining if said subsequent data block is a modification data block,wherein if said subsequent data block is not a modification data block,the processor configured to:

compute a cryptographic hash of the subsequent data block; and determineif the cryptographic hash of the subsequent data block matches acryptographic hash stored in a successor data block of the subsequentdata block, and if the cryptographic hash of the subsequent data blockdoes not match the cryptographic hash stored in the successor data blockof the subsequent data block, storing information associated with thesubsequent data block as an entry in said list;

wherein if said subsequent data block is a modification data block, theprocessor is configured to: verify an integrity measure of themodification data block; if said verification of the integrity measureof the modification data block is successful, determine that informationin the modification data block matches information of a matching entryin said list, and in response, remove said matching entry from saidlist;

in response to completion of said analysis, successfully verify the datastructure based upon detecting that said list comprises no entries.

These and other aspects will be apparent from the embodiments describedin the following. The scope of the present disclosure is not intended tobe limited by this summary nor to implementations that necessarily solveany or all of the disadvantages noted.

BRIEF DESCRIPTION OF THE DRAWINGS

For a better understanding of the present disclosure and to show howembodiments may be put into effect, reference is made to theaccompanying drawings in which:

FIG. 1 is schematic block diagram of a communication system;

FIG. 2 is a schematic block diagram of a computing device in thecommunication system;

FIG. 3 illustrates the known composition of a blockchain;

FIG. 4 illustrates how a hash chain is broken if data in a block of theblockchain is modified;

FIG. 5a is a flow chart of a process performed by a computing device inthe communication system to modify a block of a blockchain;

FIG. 5b illustrates a schematic block diagram of a modificationtransaction request

FIG. 5c illustrates a schematic block diagram of a modification record

is a schematic block diagram of an initialized security data processingdevice; and

FIGS. 6a and 6b illustrate a modification block;

FIGS. 7 illustrates a blockchain comprising a modification block; and

FIGS. 8a-c is a flow chart of a process for verifying a blockchaincomprising a modification block.

DETAILED DESCRIPTION

Embodiments will now be described by way of example only. In particular,whilst embodiments are described with reference to computing devicesmodifying data stored in a blockchain, embodiments extend to themodification of data that is stored in accordance with other distributedledger technologies.

FIG. 1 illustrates a communication system 100 comprising a plurality ofcomputing devices (also referred to herein as nodes) coupled to anetwork 108 (e.g. the Internet). For simplicity three computing devicesare shown, comprising a first computing device 102 associated with userA 112, a second computing device 104 associated with user B 114 and athird computing device 106 associated with user C 116. Each of thecomputing devices 102, 104, 106 are configured to communicate data toeach other over the network 108 so as to store data on a blockchainwhich is maintained in memory associated with each computing device, andare therefore referred to herein as participant nodes. It will beappreciated that many more participant nodes than that shown in FIG. 1that involved in storing data on the blockchain, and the communicationsystem 100 may comprise other computing devices coupled to the network108 that are not participant nodes.

Each computing device is associated with a respective user. In oneexample, user B 114 may be an industrial machine manufacturer whomanufactures a particular industrial machine, user A 112 may be afactory owner who has purchased the industrial machine, and user C 116may be a worker of the factory who is required to performs checks on theindustrial machine. In this example, each user uses their associatedcomputing device to store data on a blockchain which is maintained inmemory associated with each computing device. For example, user B 114may upon manufacture of the industrial machine, store data on theblockchain such as model number, manufacture date, country ofmanufacture etc. and after software updates have been pushed to theindustrial machine user B 114 may store data on the blockchain such assoftware upgrade version number, software upgrade etc. User A 112 uponpurchasing the industrial machine may store data on the blockchain suchas purchase date, supplier details, and after having the industrialmachine serviced may store data on the blockchain such as name ofservicer, date of service, results of service etc. User C 116 may uponperforming checks on the industrial machine may store data on theblockchain such as a parameter of the industrial machine (e.g. operatingtemperature, speed, voltage etc.), date of check, name of personperforming the check etc.

The network 108 may be any suitable network which has the ability toprovide a communication channel between the computing devices. Eachcomputing device may be, for example, a mobile phone, a personalcomputer (“PC”), a tablet, laptop, or other embedded device able toconnect to the network 108. Each computing device is arranged to receiveinformation from, and output information to, the user of the computingdevice.

FIG. 2 illustrates a detailed view of a computing device (e.g. acomputing device 104) in the communication system 100. The computingdevice 104 comprises a central processing unit (“CPU”) 200, to which isconnected a memory 206 and a network interface 212 for communicationwith the network 108. As shown in FIG. 2, the CPU 200 comprises a blockmodification module 202 and a chain verification module 204. Asdescribed in more detail below, the block modification module 202 isoperable to add a modification block to a block chain. The chainverification module 204 is operable to verify a blockchain comprising amodification block.

A blockchain comprises blocks of data. The memory 206 is configured tostore block data 208 comprising blocks of a blockchain. It will beappreciated that whilst FIG. 2 illustrates the computing device 104storing the block data 208 locally, some or all of the block data 208may be stored in one or more external storage devices (e.g. in cloudstorage or in a remote storage device coupled to the computing device104).

Whilst embodiments are described with reference to a blockchain, this isjust one example of a distributed ledger technology in which embodimentsof the present disclosure can be used in. In particular, the term“block” is used herein to refer generally to a sequence of bits or bytesstoring data, which may be added to a data structure which is structuredin accordance with a distributed ledger technology. It will beappreciated the format of the block and how it links to other blocks inthe data structure will vary in dependence on the particular distributedledger technology.

The memory also stores a consensus engine 210. The consensus engine 210comprises instructions which when executed by the CPU 202 implement aconsensus mechanism. The particular implementation details of theconsensus mechanism may vary greatly, but in a general sense, theconsensus mechanism defines how the consensus engine 210 knows how itwill be convinced that a block is valid and should be added to thechain. In particular, the consensus mechanism defines how the consensusengine 210 knows to accept a block that originated from anothercomputing device on the network, and how the consensus engine 210 canverify that a block created by the computing device 104 was accepted bythe network (i.e. accepted by consensus nodes in the network).

A consensus node (also referred to herein as a validator computingdevice) is a computing device coupled to the network 108 which plays arole in determining whether a new block is to be accepted onto theblockchain. A consensus node may also be a participant node, howeverthis is not essential and thus a consensus node may not also be aparticipant node. In implementations, the consensus nodes may correspondto one or more the participant nodes. In one implementation, theconsensus nodes may correspond to the participant nodes (i.e. all of theparticipant nodes are also involved in the consensus of whether toaccept a new block onto the blockchain that is stored by each of theparticipant nodes).

In embodiments of the present disclosure, any known consensus mechanismmay be used by the consensus engine 210. Details of the particularconsensus mechanism that is used by the consensus engine 210 fallsoutside the scope of the present disclosure, however the consensusmechanism typically falls into one of the below types:

-   -   all the authorized validator computing devices are somehow known        to the consensus engine 210, and when the consensus engine 210        is checking, it can see who and how many of the validator        computing devices have approved the new block. When enough of        the validator computing devices have approved the new block        (e.g., a predetermined number of validator computing devices        have approved the new block or a predetermined percentage of the        total validator computing devices have approved the new block)        the consensus engine 210 accepts the new block.    -   the consensus engine 210 does not know all the authorized        validator computing devices but instead stores sufficient data        and code to re-create (from first principles) some mathematical        or cryptographic puzzle that proves that they all know the same        secret, or are working together, or similar.

Although not shown in FIG. 2, the computing device 104 may comprise aninput device such as a keypad, a touch-sensitive display, and/or amicrophone. The computing device 104 may also comprise an output devicesuch as a display (which may be touch-sensitive) and/or speakers.

The computing devices 102 and 106 of the other participants of theblockchain also store their own copy of the blocks of the blockchain inmemory associated with the device.

FIG. 3 illustrates the known linear data structure of a blockchain. Atthe beginning of the blockchain there is a genesis block 302. As shownin FIG. 3, each block comprises at least one portion of data (labelledas T0-Tn), commonly referred to as transactions. Each block that followsthe genesis block 302 comprises the cryptographic hash of the precedingblock (referred to herein as a linking hash). For example, as shown inFIG. 3, block 1 (B1) 304 comprises the cryptographic hash, HASH(G)—alinking hash, of the preceding block (the genesis block 302). Similarly,block 2 (B2) 306 comprises the cryptographic hash, HASH (B1)—a linkinghash, of the preceding block (block 304). Expressed another way, thecryptographic hash of each block is stored in its successor.

The manner in which a blockchain is constructed means that it isimpossible to modify, add, or remove anything from a block that has beencommitted to the chain. This is so because the ‘nodes’ (participants) inreaching consensus and validating the chain recalculate the hash of eachblock and discard/revoke any that don't match. Any change to the data(usually ‘transactions’) in a block changes its cryptographic hash, andso breaks the chain. With the chain's integrity broken, nobody can trustthe data in the modified block or any subsequent block. This isillustrated in FIG. 4.

In FIG. 4, the modification of data (T1) 404 in block Bn 402 means thatthe hash of the whole block, Hash(Bn), changes, and so the linked hashin the next block B(n+1) 310 does not match the hash of block Bn 402 andthe chain cannot be verified. We refer herein to block B(n+1) as thesuccessor block of block Bn.

Reference is now made to FIG. 5, which shows a flow chart of a process500 performed by the block modification module 202 at the computingdevice 104. This process advantageously maintains integrity of the chainas a whole whilst enabling modification of individual data portions in adata block.

User B 114 wishing to modify one or more portions of data that is storedin a block of a blockchain stored in the block data 208 is able toselect the data to be modified. This selection may be made using aninput device of the computing device 104. At step S502, the blockmodification module 202 receives a selection of data to be modified andthus a selection of a block of the blockchain comprising the selecteddata to be modified.

At step S504, the block modification module 202 retrieves the contentsof the selected block (comprising the data to be modified) from thememory 206. The selected block remains as a block in the blockchain inunmodified form, however its contents are read by the block modificationmodule 202.

At step S506, the block modification module 202 modifies the copied databased on input received from user B 114 to create modified block data.The user B 114 may provide input to perform one of the followingmodifications (i) a redaction, whereby some of the data copied from theselected block is obscured in some way, whereby it is evident to areader of the modified block data that the data has been obscured; (ii)a deletion, whereby some of the data copied from the selected block isremoved and is not replaced; (iii) a replacement, whereby some of thedata copied from the selected block is removed and is replaced withother data; and (iv) an addition, whereby new data is added to the datacopied from the selected block. Note the modification described above isperformed on the contents copied from the selected block and notperformed on the selected block itself that has been previously beencommitted to the blockchain.

At step S508, the block modification module 202 stores the modifiedblock data in memory 206. At this point in the process, the modifiedblock data is not part of the blockchain, the blocks of which are storedin block data 208 in memory 208.

In order to have the modified block data accepted onto the blockchain,the computing device transmits a request to a plurality of consensusnodes on the network 108, this request requests permission to modify theselected data block in accordance with the modified block data. StepsS510-S520 illustrate one example of how this request may be formed andtransmitted.

At step S510, the block modification module 202 creates a modificationtransaction request 552.

The modification transaction request 552 comprises at least one dataportion identifier, each of the at least one data portion identifierassociated with a respective data portion (T0-Tn) that is beingmodified.

The modification transaction request 552 also specifies the manner bywhich the selected block is to be modified. In particular, themodification transaction request 552 may comprise the modified blockdata itself, or alternatively may convey the modifications to thecontents of the selected block that are required to arrive at themodified block data.

The modification transaction request 552 also comprises an originalcryptographic hash of the selected block (prior to any modification) anda new cryptographic hash computed from the modified block data.

The modification transaction request 552 may also comprise a blockidentifier of the block that is being modified. Typically the blockidentifier will take the form of a block number indicating the number ofblocks since the genesis block (for example in FIG. 3 block 304 wouldhave a block number of 1, block 306 would have block number of 2 etc.).

The modification transaction request may also comprise a reason as towhy user B 114 wishes to modify the at least one data portion in theselected block (e.g. privacy redaction, accuracy modification etc.). Thereason may be represented by a specific pattern of bytes.

Once the modification transaction request 552 has been created, theprocess 500 proceeds to step S512 where the computing device 104 adds anintegrity measure to the modification transaction request. As is knownto persons skilled in the art an ‘integrity measure’ is a piece ofmetadata that accompanies a piece of data to provide proof or confidencethat the data has high integrity: that is to say that it is complete(has not had portions removed or truncated); it is unmodified (no partof the data has been changed since it was created); and that it isauthentic (it really came from the person/place/device it claims to havecome from). Optionally there may also be a time or validity element todetermine whether a trusted source has been compromised or revoked(i.e., it was trusted, and the data might have been good when it wascreated, but it's not anymore). In short, this integrity measuremetadata convinces the receiver of data that they are seeing exactlywhat the sender really sent.

The integrity measure may take various forms. In one example theintegrity measure is a digital signature. In this example, at step S512the computing device 104 signs the modification transaction request 552to generate a digital signature (an integrity measure) 554, and appendsthe digital signature 554 to the modification transaction request 552 tocreate a signed modification transaction request 550. For example, thedigital signature may be created by the computing device 104 byencrypting a cryptographic hash of the modification transaction request552 using a cryptographic key (e.g. a private key) associated with thecomputing device 104. As illustrated in FIG. 5b , the signedmodification transaction request 550 comprises the modificationtransaction request 552 and the digital signature 554.

At step S514, the computing device 104 transmits the signed modificationtransaction request 550 to all of the consensus nodes that are coupledto the network 108. For example, considering the example communicationsystem 100 shown in FIG. 1, the computing device 102 and computingdevice 106 may be consensus nodes and thus the computing device 104transmits the signed modification transaction request 550 to computingdevice 102 and computing device 106 over the network 108. The computingdevice 104 transmits the signed modification transaction request 550 viathe network interface 212.

Upon receipt of the signed modification transaction request 550, each ofthe consensus nodes (e.g. computing device 102 and computing device 106)generates an integrity measure. Continuing with the example above,whereby we refer to using a digital signature as an integrity measure,each of the consensus nodes signs the modification transaction request552 to generate a digital signature (an integrity measure). For example,computing device 102 may generate a digital signature 556 by encryptinga cryptographic hash of the modification transaction request 552 using acryptographic key (e.g. a private key) associated with the computingdevice 102. Similarly, computing device 106 may generate a digitalsignature 558 by encrypting a cryptographic hash of the modificationtransaction request 552 using a cryptographic key (e.g. a private key)associated with the computing device 106.

Once each of the consensus nodes has generated their respective digitalsignature, the consensus node transmits the digital signature tocomputing device 104. Thus at step S516, the computing device 104receives a digital signature of each of the consensus nodes coupled tothe network 108. Expressed another way, if computing device 104 is aconsensus node and there is a total of n consensus nodes coupled to thenetwork 108, the computing device receives n-1 digital signatures atstep S516. For example, considering the example communication system 100shown in FIG. 1, the computing device 104 receives digital signaturesfrom computing device 102 and computing device 106.

At step S518, the computing device 104 generates a modification record560 by appending the signatures received from the consensus nodes to thesigned modification transaction request 550. As illustrated in FIG. 5c ,the modification record 560 comprises the signed modificationtransaction request 550, the digital signature 556 received fromcomputing device 102, and the digital signature 558 received fromcomputing device 102.

At step S520, the consensus engine 210 on computing device 104 submitsthe modification record 560 to the network for consensus. That is, thecomputing device 104 transmits a request to the consensus nodes on thenetwork 108 which requests permission to modify the selected data blockin accordance with the modified block data.

Once consensus has been reached, the modification record 560 iscommitted to the blockchain (added as a block at the end of theblockchain) by each of the participant nodes. That is, upon theconsensus engine 210 detecting that consensus has been reached thecomputing device 104 (and also computing device 102 and computing device106) commits the modification record 560 to the blockchain. In addition,the selected block is modified so as to comprise the modified block datareferred to above.

The modification record 560 committed to the blockchain is referred toherein as a modification block. In embodiments, a modification blockcomprises information relating to a modification of a data block in thedata structure.

If consensus is not reached (i.e. permission is not granted to modifythe selected data block in accordance with the modified block data),then the modification record 560 is not committed to the blockchain byeach of the participant nodes, and the selected block is not modified soas to comprise the modified block data and the

Whilst step S506 has been described above with reference to creatingmodified block data from contents copied from the selected block wherebythe modification is not performed on the selected block itself that hasbeen previously been committed to the blockchain, in alternativeembodiments the block modification module 202 modifies the selectedblock to create the modified block data. In these alternativeembodiments, if consensus is not reached the block modification module202 reverses the modifications so that the selected block is in itsoriginal form.

Furthermore, whilst process 500 has been described above with referenceto integrity measures being digital signatures, this is merely anexample.

In an alternative embodiment, at step S512 instead of the computingdevice 104 adding a digital signature to the modification transactionrequest, the computing device 104 may generate an integrity measure inthe form of a Message Authentication Code (“MAC”) by providing themodification transaction request and a symmetric key as inputs into aMAC algorithm which computes the MAC using known methods. In thisexample, upon receipt of the modification transaction request 550appended with a MAC code generated by the computing device 104, each ofthe consensus nodes generate a MAC code using the symmetric key andsupply this to the computing device 104 for use in generating themodification record at step S518.

In another alternative embodiment, at step S512 instead of the computingdevice 104 adding a digital signature to the modification transactionrequest, the computing device 104 may generate an integrity measure inthe form of a cryptographic hash by inputting the modificationtransaction request into a one-way hash function. In this example, uponreceipt of the modification transaction request 550 appended with acryptographic hash generated by the computing device 104, each of theconsensus nodes generate a cryptographic hash using the same one-wayhash function and supply this to the computing device 104 for use ingenerating the modification record at step S518.

In another alternative embodiment, at step S512 instead of the computingdevice 104 adding a digital signature to the modification transactionrequest, the computing device 104 may generate an integrity measure inthe form of a reference to a server (e.g. a server hosting an onlinedirectory or a measurement server). This reference enables a deviceattempting to verify the integrity of the modification block 600 toquery the server in order to carry out the verification process. Valuescan be stored in a known online directory then relying parties cancontact that directory to either pull good values (for checking later)or ask the online directory whether the data in the modification blockis trusted/legitimate questions. In this case the process of checkingthe integrity of the modification block 600 involves asking and checkingthe answers (which may carry individual measures of their own). Ameasurement server is a third party server that knows the “measurements”of data which replying parties can check before they trust it. Themeasurement server acts as a central authority which can measure (forinstance checksum, or hash, or manifest) the approved data and put thatmeasurement on a trusted server. This may provide a more flexiblesolution than use of a digital signature in some cases, since it allowsfor more practical extension or individual customization of thecode/data across a broad population of users. Similarly at step S516,the integrity measure received from one or more of the consensus nodesmay be in the form of a reference to a server.

FIG. 6a illustrates a modification block 600.

As noted above, the modification block 600 is added as a block e.g.block B(m), at the end of the blockchain. As with any block on ablockchain, the modification block 600 comprises the cryptographic hashof the preceding block (B(m−1) 602. The modification block 600 also hascontents comprising:

at least one data portion identifier 604 associated with a respectivedata portion (T0-Tn) that was modified (the at least one data portionidentifier 604 having been included in the modification transactionrequest 552);

the original cryptographic hash 608 of the block that was modified priorto modification (the original cryptographic hash 608 having beenincluded in the modification transaction request 552);

the new cryptographic hash 610 of the block that was modified postmodification (the new cryptographic hash 610 having been included in themodification transaction request 552);

an integrity measure 612 that ensures that the contents (e.g. (a)-(c))are immutable.

Optionally, the modification block 600 contents comprise a modifiedblock identifier 606 of the block that was modified, thus the modifiedblock is easily identifiable.

Optionally, the modification block 600 contents comprises the modifiedblock data (the new contents of the modified block). This may beunnecessary since the cryptographic hash of the modification block 600will say if the contents are correct or not, but having the modifiedblock data available provides information as to why and how themodification was made e.g. privacy redaction, accuracy modificationetc.).

The integrity measure 612 may correspond to the digital signatures 554,556, and 558 of the computing device 104 (consensus node) that submitsthe modification record to the blockchain. Thus the participantcomputing devices involved in creating the modification are clearlyidentified (since the public keys of the computing devices 102, 104 and106 are unique and known). Alternatively, the integrity measure 612 maycorrespond to a single signature associated with multiple consensusnodes. For example, the integrity measure 612 may be a multi-partysignature associated with the computing device 104 and the otherconsensus nodes (e.g. computing device 102 and computing device 106). Asis known in the art, a multi-party signature is a digital signaturewhich allows a group of users to sign data, whereby the joint signatureis more compact than a collection of distinct signatures from each ofthe users. The multi-party signature may be in the form of a groupsignature or a ring signature.

The cryptographic hash 614 of the modification block 600 will beinserted into the next block added to the blockchain.

FIG. 6b illustrates a modification block 600 for the examplemodification shown in FIG. 4 whereby data portion (T1) in block B(n) inthe blockchain has been modified. In this scenario, the modificationblock 600 comprises:

a) a data portion identifier 604 of data portion T1;

b) a modified block identifier 606 of block B(n);

c) the original cryptographic hash 608 of block B(n) prior tomodification—HASH B(n);

d) the new cryptographic hash 610 of block B(n) post modification—HASHB(n)′

e) an integrity measure 612

FIG. 7 illustrates the modified blockchain (comprising a modificationblock) with integrity intact. As shown in FIG. 7, data portion (T1) 404of data block B2 306 has been modified and a modification block 600 hasbeen added to the blockchain. As shown in FIG. 7 following the additionof the modification block 600, new blocks (e.g. block 310) may be addedto the blockchain in accordance with known methods. Following themodification of the data block, each of the computing devices do notretain a copy in memory of the original data block prior tomodification.

In embodiments of the present disclosure the chain remains verifiable,the modification to a block is easily identifiable (without giving awaythe original data) and the number of other transactions that becomequestionable is limited only to the ones in that same block. This is avery significant advance in the trustworthiness of distributed ledgersin general, and blockchain in particular.

Known methods for maintaining secrecy or privacy of data are based on‘confidential transactions’ or ‘channels’ which encrypt the data invarious ways prior to writing it to the blockchain, but these methodsare unsatisfactory because the data is still retrievable by parties whowere privy to the transaction, and it is necessary to protect theinformation up-front, essentially requiring impossible levels ofprediction as to which transactions will become sensitive or dangerouslater on.

Reference is now made to FIG. 8a -c, which shows a flow chart of aprocess 800 for verifying the integrity of a blockchain comprising amodification block performed by a chain verification module 204 on acomputing device.

The process 800 may be performed by the chain verification module 204 ona computing device 102,104,106 upon joining the network 108 as a newnode and receiving a copy of the blockchain established by theparticipant nodes prior to the computing device 104 joining the network108. Alternatively, the process 800 may be performed by the chainverification module 204 on a computing device 102,104,106 who hasparticipated in establishing the blockchain but who has lost a copy ofthe blockchain from their memory. Alternatively, the process 800 may beperformed by a validating device who has not and will not participate inestablishing and maintaining the blockchain, but needs to validate thecompleteness and integrity of the chain (e.g. an auditor or legalauthority). Such a validating device comprises a chain verificationmodule 204 but does not necessarily comprise a block modification module202.

The process 800 starts at step S802, where the value n, indicative ofthe block being checked, is initialized to zero.

At step S804 the chain verification module 204 reads block B(n) from theblockchain, with the value of n set to zero, the chain verificationmodule 204 checks the contents of the genesis block (i.e. the block atthe beginning of the blockchain).

At step S806 the chain verification module 204 computes thecryptographic hash of block B(n).

At step S808 the chain verification module 204 reads the next block onthe blockchain block B(n+1) which is the block immediately followingblock B(n) i.e. block B(n+1) is the successor block to block Bn.

At step S810, the chain verification module 204 determines whether thecryptographic hash of block B(n) is included in block B(n+1). Forexample, when step S810 is implemented for the first time this stepinvolves checking whether the cryptographic hash of the genesis block isincluded in the block immediately following the genesis block.

If it is determined at step S810 that the cryptographic hash of blockB(n) is not included in block B(n+1), then this indicates that at leastone data portion of the genesis block has been modified and the process800 proceeds to step S812 where information of block B(n) is stored in alist of unmatching blocks that maintained in memory of the computingdevice. An entry in this list for a modified block B(n) following thisstoring step may comprise one or more of: (i) a block identifier of themodified block B(n); (ii) the cryptographic hash of the modified blockB(n); and (iii) the cryptographic hash included in block B(n+1) (i.e.the original cryptographic hash of block B(n) prior to modification).

If it is determined at step S810 that the cryptographic hash of blockB(n) is included in block B(n+1), then this indicates that block B(n)has not been modified, and the process 800 proceeds to step S814 wherethe value of n is incremented by 1 and at step S816 the next block Bn(the block after the genesis block) is read by the chain verificationmodule 204.

If this block Bn is not a modification block (determined at step S816)and the end of the chain has not been reached (determined at step S818)then the process 800 proceeds back to step S806 where the chainverification module 204 computes the cryptographic hash of the block Bn.The determination at step S816 as to whether block Bn is a modificationblock may comprise whether the block Bn has contents in a formatassociated with a modification block.

Thus for each block (that is not a modification block) in theblockchain, the chain verification module 204 checks whether acryptographic hash of the contents of the block matches a cryptographichash of the next block on the blockchain.

FIG. 8b illustrates the steps performed by the chain verification module204 upon encountering a modification block 600 (determined at stepS810).

The chain verification module 204 may detect that a block Bn is amodification block 600 in one of numerous ways. In one example, thechain verification module 204 detects that a block Bn is a modificationblock based on the structure of the block corresponding to apredetermined structure associated with a modification block. That is,the chain verification module 204 detects that a block Bn is amodification block based on determining that the block Bn has datafields associated with a modification block (e.g. at least one dataportion identifier 604, an original cryptographic hash 608, a newcryptographic hash 610, and an integrity measure 612).

When a modification block 600 is encountered (determined at step S816)the process 800 proceeds to step S830 where the chain verificationmodule 204 attempts verification of the integrity measure 612 of themodification block 600. In the example whereby the integrity measure 612corresponds to the digital signatures 554, 556, and 558, at step S830the chain verification module 204 attempts verification of each of thedigital signatures 554, 556, and 558. For example verification of thedigital signature 554 the computing device is performed by decryptingthe digital signature 554 using the public key of the computing device104 and checking that the resulting hash matches a cryptographic hash ofthe contents of the modification block 600.

In another example, verification of the integrity measure 554 when it isin the form of a Message Authentication Code (“MAC”) would compriseproviding the modification transaction request of the modification block600 and the symmetric key as inputs into a MAC algorithm in order tocompute a MAC using known methods and comparing the computed MAC to theMAC provided in the modification block 600. In a similar manner,verification of the integrity measure 554 when it is in the form of acryptographic hash would comprise providing the modification transactionrequest as an input into a one-way hash function and comparing thecryptographic hash to the cryptographic hash provided in themodification block 600.

In yet another example, verification of the integrity measure 554 whenit is in the form of a reference to a server would comprise transmittinga query to the server and processing the reply from the server in orderto carry out the verification process.

At step S832 the chain verification module 204 determines whether thisattempt at verification has been successful or not. If it is determinedat step S832 that verification of the integrity measure 612 of themodification block 600 is successful, then the process 800 proceeds tostep S834.

At step S834, the chain verification module 204 determines whether thelist of unmatching blocks comprises an entry matching the contents ofthe modification block 600.

Step S834 may be performed in various ways.

In embodiments where, at step S812, the chain verification module 204stores the cryptographic hash included in block B(n+1) (i.e. theoriginal cryptographic hash of block B(n) prior to modification) in anentry in the list of unmatching blocks, S834 may comprise the chainverification module 204 determining whether the list of unmatchingblocks comprises an entry which includes a cryptographic hashcorresponding to the original cryptographic hash 608 included in themodification block 600

In embodiments where, at step S812, the chain verification module 204stores the cryptographic hash of the modified block B(n) in an entry inthe list of unmatching blocks, S834 may comprise the chain verificationmodule 204 determining whether the list of unmatching blocks comprisesan entry which includes a cryptographic hash corresponding to the newcryptographic hash 610 included in the modification block 600

In embodiments where, at step S812, the chain verification module 204stores a block identifier of the modified block B(n) in an entry in thelist of unmatching blocks, S834 may comprise the chain verificationmodule 204 determining whether the list of unmatching blocks comprisesan entry which includes a block identifier corresponding to the modifiedblock identifier 606 of the modification block 600

If the chain verification module 204 determines at S834 that the list ofunmatching blocks comprises an entry matching the contents of themodification block 600,the process proceeds to step S836 where the chainverification module 204 removes the entry matching the modificationblock 600 from the list of unmatching blocks and the process proceeds toS818 shown in FIG. 8 a.

If the chain verification module 204 determines at S834 that the list ofunmatching blocks does not comprise an entry matching the contents ofthe modification block 600, the process proceeds to step S838 where theverification of the integrity of the blockchain fails.

Referring back to step S832, if it is determined at step S832 thatverification of the integrity measure 612 of the modification block 600is not successful, then the process 800 proceeds to step S838 where theverification of the integrity of the blockchain fails.

FIG. 8c illustrates the steps performed by the chain verification module204 upon determining that the end of the blockchain has been reached(determined at step S818).

When the chain verification module 204 detects, at step S818, that theend of the blockchain has been reached the process 800 proceeds to stepS850.

At step S850, the chain verification module 204 determines whether thereis any entries remaining in the list of unmatching blocks maintained inmemory of the computing deice.

If it is determined at step S850 that there is no entries remaining inthe list (due to the removal of an entry each time step S836 isperformed) then the process 800 proceeds to step 852 where the chainverification module 204 successfully verifies the integrity of theblockchain.

If it is determined at step S850 that there are one or more entriesremaining in the list then the process 800 proceeds to step 854 wherethe verification of the integrity of the blockchain fails.

Upon detecting failure of the verification of the blockchain on acomputing device performing the process 800 in order to join thenetwork, the computing device will not accept the data of the blockchain(which failed verification) i.e. it will not store the data of theblockchain in memory, and will not join the network.

Similarly, upon detecting failure of the verification of the blockchainon a computing device performing the process 800 in order to re-obtain alost copy of the data of the blockchain, the computing device will notaccept the data of the blockchain (which failed verification) i.e. itwill not store the data of the blockchain in memory. Furthermore, in theevent that the computing device was acting as a consensus node prior tolosing the data of the blockchain, the computing device will no longerparticipate in consensus following the failed verification.

Upon detecting failure of the verification of the blockchain on avalidating device who has not and will not participate in establishingand maintaining the blockchain, the validating device may perform one ormore operations, the one or more operations including for example:storing information relating to the failed verification; shut-down; wipeits memory and start the verification process again once it re-receivesthe blocks of the blockchain; wait for a predetermined amount of timebefore restarting the verification process; emit an attack beacon (e.g.a packet which when received by other nodes notifies them of thepossible forgery that triggers a recovery process). It will beappreciated that these are merely examples.

Generally, any of the functions described herein can be implementedusing software, firmware, hardware (e.g., fixed logic circuitry), or acombination of these implementations. The terms “module” as used hereingenerally represent software, firmware, hardware, or a combinationthereof. In the case of a software implementation, the module representsprogram code that performs specified tasks when executed on a processor(e.g. CPU or CPUs). The program code can be stored in one or morecomputer readable memory devices. The features of the techniquesdescribed below are platform-independent, meaning that the techniquesmay be implemented on a variety of commercial computing platforms havinga variety of processors.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed:
 1. A method of modifying a data block of a datastructure comprising a plurality of linked data blocks, the methodimplemented on a computing device, and comprising: receiving a selectionof said data block comprising block data; creating modified block databased on the block data and user input received at the computing device;transmitting a request to a plurality of validator computing devicesover a communication network, said request comprising a modificationrecord and requesting permission to modify said data block in accordancewith the modified block data, wherein said modification record comprises(i) at least one data portion identifier of said block data, each of theat least one data portion identifier associated with a respective dataportion of said data block modified in creating the modified block data;(ii) modification information; (iii) a cryptographic hash of said datablock when comprising the block data; (iv) a cryptographic hash of saiddata block when comprising the modified block data; and (v) an integritymeasure; determining that consensus is reached by the plurality ofvalidator computing devices that said data block can be modified inaccordance with the modified block data; in response to saiddetermining: modifying said data block in accordance with the modifiedblock data; and adding a modification data block to the data structurecomprising the plurality of linked data blocks, the modification datablock comprising: the modification record and a cryptographic hash of adata block that precedes the modification data block after addition ofthe modification data block to the data structure.
 2. The method ofclaim 1, wherein the modification information comprises the modifiedblock data.
 3. The method of claim 1, wherein the modificationinformation comprises instructions on how to generate the modified blockdata.
 4. The method of claim 1, wherein the modification recordadditionally comprises a block identifier associated with said datablock.
 5. The method of claim 1, wherein the modification recordadditionally comprises a reason specifying why the data block is beingmodified.
 6. The method of claim 1, wherein the modifying said datablock comprises one or more of: redacting data in a data portion of saiddata block; deleting data in a data portion of said data block;replacing data in a data portion of said data block with replacementdata; and adding new data to a data portion of said data block.
 7. Themethod of claim 1, wherein said integrity measure comprises at least onedigital signature.
 8. The method of claim 1, wherein said integritymeasure comprises at least one Message Authentication Code.
 9. Themethod of claim 1, wherein said integrity measure comprises at least onecryptographic hash.
 10. The method of claim 1, wherein the modificationdata block additionally comprises the modified block data.
 11. Themethod of claim 1, wherein the data structure comprising the pluralityof linked data blocks is stored in memory of the computing device. 12.The method of claim 1, wherein the data structure is structured inaccordance with a distributed ledger technology.
 13. The method of claim12, wherein the distributed ledger technology is blockchain.
 14. Acomputer-readable storage medium comprising instructions which, whenexecuted by a processor of a computing device cause the computing deviceto perform the method of claim
 1. 15. A computing device for modifying adata block of a data structure comprising a plurality of linked datablocks, wherein the data structure is stored in memory accessible to thecomputing device, and the computing device comprising a processorconfigured to: receive a selection of said data block comprising blockdata; create modified block data based on the block data and user inputreceived at the computing device; transmit a request to a plurality ofvalidator computing devices over a communication network, said requestcomprising a modification record and requesting permission to modifysaid data block in accordance with the modified block data, wherein saidmodification record comprises (i) at least one data portion identifierof said block data, each of the at least one data portion identifierassociated with a respective data portion of said data block modified increating the modified block data; (ii) modification information; (iii) acryptographic hash of said data block when comprising the block data;(iv) a cryptographic hash of said data block when comprising themodified block data; and (v) an integrity measure; determine thatconsensus is reached by the plurality of validator computing devicesthat said data block can be modified in accordance with the modifiedblock data; in response to said determination: modify said data block inaccordance with the modified block data; and add a modification datablock to the data structure comprising the plurality of linked datablocks, the modification data block comprising: the modification recordand a cryptographic hash of a data block that precedes the modificationdata block after addition of the modification data block to the datastructure.
 16. A method of verifying a data structure comprising aplurality of linked data blocks, the method performed on a computingdevice, and comprising: for a first data block at a beginning of thedata structure: computing a cryptographic hash of the first data block;determining if the cryptographic hash of the first data block matches acryptographic hash stored in a successor data block of the first datablock, and if the cryptographic hash of the first data block does notmatch the cryptographic hash stored in the successor data block of thefirst data block, storing information associated with the first datablock as an entry in a list stored in memory accessible by the computingdevice; analysing each subsequent data block in the data structure aftersaid first data block by: determining if said subsequent data block is amodification data block, wherein if said subsequent data block is not amodification data block, the method comprising: computing acryptographic hash of the subsequent data block; determining if thecryptographic hash of the subsequent data block matches a cryptographichash stored in a successor data block of the subsequent data block, andif the cryptographic hash of the subsequent data block does not matchthe cryptographic hash stored in the successor data block of thesubsequent data block, storing information associated with thesubsequent data block as an entry in said list; wherein if saidsubsequent data block is a modification data block, the methodcomprising: verifying an integrity measure of the modification datablock; if said verifying the integrity measure of the modification datablock is successful, determining that information in the modificationdata block matches information of a matching entry in said list, and inresponse, removing said matching entry from said list; in response tocompletion of said analysing, successfully verifying the data structurebased upon detecting that said list comprises no entries.
 17. The methodof claim 16, wherein the method comprises determining that verifying thedata structure has failed if said verifying the integrity measure of themodification data block is unsuccessful.
 18. The method of claim 16,wherein in response to completion of said analysing, the methodcomprises determining that verifying the data structure has failed upondetecting that said list comprises one or more entries.
 19. Acomputer-readable storage medium comprising instructions which, whenexecuted by a processor of a computing device cause the computing deviceto perform the method of claim
 16. 20. A computing device for verifyinga data structure comprising a plurality of linked data blocks, whereinthe data structure is stored in memory accessible to the computingdevice, and the computing device comprising a processor configured to:for a first data block at a beginning of the data structure: compute acryptographic hash of the first data block; determine if thecryptographic hash of the first data block matches a cryptographic hashstored in a successor data block of the first data block, and if thecryptographic hash of the first data block does not match thecryptographic hash stored in the successor data block of the first datablock, storing information associated with the first data block as anentry in a list stored in memory accessible by the computing device;analyse each subsequent data block in the data structure after saidfirst data block by: determining if said subsequent data block is amodification data block, wherein if said subsequent data block is not amodification data block, the processor configured to: compute acryptographic hash of the subsequent data block; and determine if thecryptographic hash of the subsequent data block matches a cryptographichash stored in a successor data block of the subsequent data block, andif the cryptographic hash of the subsequent data block does not matchthe cryptographic hash stored in the successor data block of thesubsequent data block, storing information associated with thesubsequent data block as an entry in said list; wherein if saidsubsequent data block is a modification data block, the processor isconfigured to: verify an integrity measure of the modification datablock; if said verification of the integrity measure of the modificationdata block is successful, determine that information in the modificationdata block matches information of a matching entry in said list, and inresponse, remove said matching entry from said list; in response tocompletion of said analysis, successfully verify the data structurebased upon detecting that said list comprises no entries.